EnigmA Amiga Run 1995 November/EnigmA AMIGA RUN 02 (1995)(G.R. Edizioni)(IT)[!][issue 1995-11][Skylink CD].iso/earcd/docs/lwml9505.lha/LWML9505.TXT/[e-mail]_Wed May 10 22:56:09 1995.msg

Internet Message Format | 1995-06-03 | 4KB

Received: by webcom.com
    (1.37.109.15/16.2) id AA255731769; Wed, 10 May 1995 22:56:09 -0700
Return-Path: <[e-mail]>
Received: from mail04.mail.aol.com by webcom.com with ESMTP
    (1.37.109.15/16.2) id AA255641751; Wed, 10 May 1995 22:55:58 -0700
Received: by mail04.mail.aol.com
    (1.37.109.11/16.2) id AA077731912; Thu, 11 May 1995 01:58:32 -0400
Date: Thu, 11 May 1995 01:58:32 -0400
From: [e-mail]
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: PAR Q-Factor
Sender: [e-mail]
Precedence: bulk

In a message dated 95-05-10 20:52:32 EDT, you write:

>Anyone know how to set the Q-Factor before saving a animation.
>I constantly have to re-render and adjust the Q-factor. Am I doing
>something wrong?

My only experience is from the Amiga/Zorro PAR and any comments
given here are from what I understand about the PAR's workings.
If anyone knows better, please correct me.

For a quick answer, animations should ALWAYS have the Q-Factor
set to 23. A block size of 156 works for 98% of all animations. If you
have very complicated images ( detailed high contrast ) in your
animations, you might need to stretch the block size to 185 or so.

And Now For the REST of the Story...

The balance of Q-Factor and Block Size ( per frame ) are not the
only factors in the record/playback formula. TIME and data rate
play a major role in getting the best performance out of the PAR.

Recording RGB files...
The ASIC chips on the PAR need time to perform their appointed
tasks. When recording an animation frame by frame, the PAR has
at least a few seconds to compress the frame and add it to the
animation. Knowing this, the software takes the time to compute
a high quality image while managing to also fit it into a relatively
small block size.

Recording Video.... ( All the rules change )
Using the TBC-IV you can record video on your PAR. Now you're
providing such a HUGE stream of data that the ASICs only have the
time to take a quick stab at compressing each video frame. The
block size required to record each video frame is therefore MUCH
higher v.s. a frame of animation. I don't recommend using a Q-Factor
higher than 13 for video. Otherwise your block size will need to be
so large your disk will fill in no time. If you have the luxury of
multiple recording attempts I recommend you choose a Q-Factor,
set an unusually high block factor, record the video, and then use
the "Chart" feature to determine what block size would be optimum.
I have used block sizes as high as 300 for critical stuff.

Playback....
Another variable to keep in mind is the data rate between the PAR
and the attached IDE drive. If you try pushing your block sizes
larger than the drive can handle you'll just end up with corrupted
files that play back garbage.

Likewise the block size will also dictate your success for playing
a file back at speeds other than 30 fps. I'm not real strong on
theories of disk interleaving, but I do know that animations that use
large block sizes may play back at 30 fps, but NOT 15 fps!

>Does anyone know if the new PVR has the same problem or does
>it auto-adjust?

>From what I've read in the press release, it chooses an appropriate
Q-Factor for EACH frame on the fly. ( I'm saving my pennies to get
one )

Dan Esmond
Animagic
Austin, TX
--
[e-mail] sent this message.
To Post a Message           : [e-mail]
Un/Subscription Requests To : [e-mail]
(DIGEST)                 or : [e-mail]
Administrative Items To     : [e-mail]